Verified AccessにおいてAWS IAM Identity Centerの設定に基づくポリシー評価を試してみた

yhana

2023.05.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Verified Access が GA されました。自身の勉強も兼ねて、ドキュメントに例示されている内容を中心に AWS IAM Identity Center の設定に基づく評価を試してみました。

本ブログで試しているのは次の評価です。

すべての IAM Identity Center ユーザーを許可
IAM Identity Center のグループ ID で許可
IAM Identity Center の複数のグループ ID で許可
プライマリ E メールアドレスのドメインで許可

AWS Verified Access の設定は下記のブログが参考になります。

2023.5.12 追記
AWS ブログにおいてポリシーの使用例を紹介するブログが公開されました

試した環境

本ブログで検証した環境の設定を記載します。

AWS Verified Access の設定

Verified Access 信頼プロバイダーの設定です。信頼プロバイダーは AWS IAM Identity Center です。

Verified Access インスタンスの設定です。

Verified Access グループの設定です。

Verified Access エンドポイントの設定です。下記画像に収まっていないポリシー設定とタグはデフォルトのままです。

アクセスする Web システム

Internal ALB の後ろに Apache2 をインストールした EC2 インスタンス 1 台のシンプルな構成です。

アプリケーションドメインsecured.access.example.net (example.net は例示の値に変更しています) の証明書の発行と Verified Access のエンドポイント URL を応答する Route 53 の CNAME レコードも設定しています。

ポリシー設定のお試し

ポリシー設定を試す前に、評価を検討する際に重要となるポリシーに関するドキュメントを紹介します。

ポリシー設定について

Verified Access グループ、または、エンドポイントに記載するポリシーの記載ルールは次のドキュメントに説明があります。

Verified Access policies - AWS Verified Access

Verified Access のポリシーでは信頼データに対して評価ルールを記載できます。信頼データは信頼プロバイダーに関係ない共通的な内容と信頼プロバイダー個別の内容があります。

信頼プロバイダーに関係ない信頼データは次のドキュメントに説明があります。例えば、HTTP のメソッドや　 User-Agent などが含まれています。

Verified Access default context - AWS Verified Access

今回の検証で信頼プロバイダーとして設定した AWS IAM Identity Center から渡される信頼データは次のドキュメントに詳細があります。

AWS IAM Identity Center - AWS Verified Access

AWS IAM Identity Center の信頼データを抜粋して記載します。現在は役職や部署名、ロケールなどの属性情報には対応していないようです。

{
   "title": "AWS IAM Identity Center context specification",
   "type": "object",
   "properties": {
     "user": {
       "type": "object",
       "properties": {
         "user_id": {
           "type": "string",
           "description": "a unique user id generated by AWS IdC"
         },
         "user_name": {
           "type": "string",
           "description": "username provided in the directory"
         },
         "email": {
           "type": "object",
           "properties": {
             "address": {
               "type": "email",
               "description": "email address associated with the user"
             },
             "verified": {
               "type": "boolean",
               "description": "whether the email address has been verified by AWS IdC"
             }
           }
         }
       }
     },
     "groups": {
       "type": "object",
       "description": "A list of groups the user is a member of",
       "patternProperties": {
         "^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$": {
           "type": "object",
           "description": "The Group ID of the group",
           "properties": {
             "group_name": {
               "type": "string",
               "description": "The customer-provided name of the group"
             }
           }
         }
       }
     }
   }
 }

以上を踏まえて、AWS IAM Identity Center で次のユーザーとグループをテスト用に作成して試してみました。

項目名	ユーザー 1	ユーザー 2	ユーザー 3	備考
ユーザー名	developer	developer2	operator
グループ	developer-group	developer-group	operator-group
プライマリ E メール	@gmail.com	@gmail.com	@classmethod.jp	ホスト名は省略して記載
メールの検証	検証済	未検証	検証済

ドキュメントで例示されている内容を参考に、AWS IAM Identity Center の設定情報に基づく評価をいくつか試してみました。

すべての IAM Identity Center ユーザーを許可

AWS IAM Identity Center の認証が成功であれば許可する例です。

permit(principal,action,resource)
when {
    true
};

アクセスを試した結果です。

developerユーザー：◯（アクセス成功）
developer2ユーザー：◯（アクセス成功）
operatorユーザー：◯（アクセス成功）

IAM Identity Center のグループ ID で許可

AWS IAM Identity Center のグループ ID が一致すれば許可する例です。冒頭で紹介したブログでも設定されている内容です。

developerユーザーが所属するdeveloper-groupのグループ ID を指定しています。

permit(principal,action,resource)
when {
    context.idc.groups has "444884f8-c051-701b-e112-d71074388fb0"
};

アクセスを試した結果です。

developerユーザー：◯（アクセス成功）
developer2ユーザー：◯（アクセス成功）
operatorユーザー：✕（アクセス失敗）

IAM Identity Center の複数のグループ ID で許可

AWS IAM Identity Center のグループ ID を複数指定する例です。or 条件です。

developer-groupとoperator-groupのグループ ID を指定しています。

permit(principal,action,resource)
when {
    context.idc.groups has "444884f8-c051-701b-e112-d71074388fb0"
    || context.idc.groups has "a4787448-90e1-709c-a3fd-14c35c346fa5"
};

アクセスを試した結果です。

developerユーザー：◯（アクセス成功）
developer2ユーザー：◯（アクセス成功）
operatorユーザー：◯（アクセス成功）

プライマリ E メールアドレスのドメインで許可

AWS IAM Identity Center のユーザーに設定するプライマリ E メールアドレスのドメイン名が指定した内容と一致、かつ、メールアドレスが検証済の場合に許可する例です。

例えば、所属組織が異なるユーザーを AWS IAM Identity Center で管理している場合に、特定の組織のユーザーをドメイン名で識別して許可する、といった使い方ができそうです。

permit(principal, action, resource)
when {
    context.idc.user.email.address like "*@gmail.com"
    && context.idc.user.email.verified == true
};

アクセスを試した結果です。

developerユーザー：◯ アクセス可能
developer2ユーザー：✕（アクセス失敗）
operatorユーザー：✕（アクセス失敗）

ドメイン名で評価する部分は AWS のブログでも紹介されています。

AWS Verified Access プレビュー – 企業アプリケーションへの VPN レスの安全なネットワークアクセス | Amazon Web Services ブログ

さいごに

AWS Verified Access が GA されたため、早速、AWS IAM Identity Center の設定内容に基づく評価を試してみました。今回は、AWS IAM Identity Center の設定のみを条件としましたが、デバイスの状況も組み合わせて評価することで、できることが増えそうです。

以上、このブログがどなたかのご参考になれば幸いです。